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1. The attachOverride Option 


Section 5.1 contains the APEX option registration for the 


"attachOverride" option. 


The default behavior of the APEX relaying mesh, 


processing options, 
a particular endpoint, 
"attachOverride" 
application trying to attach. 


ona 


If this option is present in the 
4.4.1 of 111) 
specified endpoint, 
(c.f., Section 4.4.3 of 111) 


"attach" operation. The "code" 


"attach" 
and if any application is already attached as the 
that endpoint has its attachment terminated 
concurrently vith processing of that 
attribute of the resulting 
"terminate" operation is set to 556. 


in the absence of 


is to allov at most one application to attach as 
"first come, 
option provides gives preference to the current 


first served" basis. The 


operation (c.f., Section 


Note that any data being expected by the previously-attached 
application may instead be delivered to the last application to 


successfully attach. Accordingly, 


applications should take care to 


properly deal vith incoming data having unrecognized transaction- 


identifiers (c.f., 


Kilyne, et. al. 


Standards Track 


Section 6.1.1 of 111). 
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This option provides for a nev attachment to automatically terminate 
any existing attachment for the same endpoint. For example, this 
might be helpful vhen a nev attachment is required from a different 
device vhile a previously-used device is still attached e.g9., 


C: cattach endpointe“” fredüexample.com” trans1IDe”1” /5 
S: cok /3 


some time later appl £f2 starts on a different computer 


C: cattach endpoint”€” fredüexample.com” trans1IDe”2”5 
xoption internal” attachOverride” transIDe”3” /x 
x/attach” 
S: cok /3 


C: €terminate trans1D€”1” codem” 556” ”overridenc/terminatexv 
S: cok /5 


2. The dataTiming Option 


Section 5.2 contains the APEX option registration for the 
"dataTiming" option. This option contains a "dataTiming" element 
(c.f., Section 6). 


The default behavior of the APEX relaying mesh is "immediate, best 
effort", and expects that all relays and endpoints are able to 
process and transfer data vithout delay -- in the absence of 
processing options, if a relay is unavailable, then data is silently 
dropped. The "dataTiming" option provides for controlled queuing 
delays in processing, vhilst providing reasonable deterministic 
behavior for the originator. 
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There are tvo types of delays addressed by the "dataTiming" option: 


o delays in transit through the relaying mesh, possibly due to 
intermittent or slov connections, or congested relays, and, 


o delays because the intended endpoint is not available to receive 
the data, vhen used in conğunction vith the holdi4Endpoint option 
(Section 3). 


Accordingly, the "dataTiming" option allovs for: 


o data to be discarded if not delivered vithin a finite amount of 
time as specified using the "noLaterThan" attribute (Section 2.1), 


Oo a "statusResponse" message (c.f., Section 5.1 of (11) to be 
generated if data is not delivered vithin a knovn amount of time 
as specified using the "reportAfter" attribute (Section 2.2), and, 


o an upper limit on the amount of time for the "statusResponse" 
message to be delivered using the "returnTrip" attribute (Section 
2.1.1), after vhich the sender may presume the message to be lost. 


This option does not provide any functionality vith respect to the 
priority of the data. Nor does this option have any effect on other 
parts of the relaying process. 


Further, note that because this option is processed on a per-hop 
basis, the originator must set the "targetHop" attribute to the value 
"all" and the "mustUnderstand" attribute to the value "true". 


2.1 Upper-Bounds on Delivery 


The "noLaterThan" attribute of the "dataTiming" option provides for 
control over delays that may occur in transit through the relaying 
mesh or to the recipient endpoint. 


If this option is present in the "data" operation (c.f., Section 
4.4.4 of 111) and the value of the "noLaterThan" attribute is non- 
zero, then: 


o For Step 5.2 of Section 4.4.4.1 of (11: 


Immediately prior to sending the data to the next relay, the value 
Of the "noLaterThan" attribute is adğusted to reflect the 
processing time of the data at the local relay (e.g., the time 
required to determine the next relay, to successfully issue a 
"bind" operation, and then be ready to immediately issue a "data" 
operation). 
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If the value of the "noLaterThan" attribute becomes less than or 
equal to zero, an error in processing has occurred, the data 
element is not sent to the next relay, and if the "reportErrors" 
attribute is true, the APEX report service is invoked to send a 
timing error report. 


For Step 5.3 of Section 4.4.4.1 of (11: 


If the relay does not receive an "ok" element from the recipient 
endpoint vithin the number of milli-seconds indicated by the value 
Of the "noLaterThan" attribute, an error in processing has 
occurred, and if the "reportErrors" attribute is true, the APEX 
report service is invoked to send a timing error report. 


Othervise, if the data is successfully transmitted to the 
recipient, and the "returnTrip" attribute is non-zero, the APEX 
report service is invoked to send a final hop report. 


Note that in some cases, a relay may be able to predict this outcome 
vithout actually connecting to the next relay, if so, a timing error 
report may be sent vithout connecting to the next relay. 


Zel. 


If 


Final Hop Report 


the APEX report service (c.f., Section 6.2 of 1f11) is invoked to 


send a final hop report, it issues a data operation vith: 


o 


Kilyne, 


its originator identifying the report service associated vith the 
issuing relay 


its recipient identifying the endpoint address of the originator 
associated vith the "dataTiming" option 


a nev "dataTiming" option having: 


8 its "noLaterThan" attribute equal to the "returnTrip" attribute 
Of the original "dataTiming" option 


8 and no other attributes present 
its content consisting of a "statusResponse" element having: 


8 its "transID" attribute equal to the "transID" attribute of the 
"dataTiming" option 


8 and identifying the original recipient vith a permanent success 
indicator 
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For example: 


C: €data contente€” cid:180example.com”x 
xoriginator identity-” fred€example.com” /x” 
xrecipient identity“” barneyğexample.com” /5 
xoption internal“”dataTiming” targetHope”all” 
mustUnderstand””true” trans1IDe”86”5 
xdataTiming noLaterThan-” 10000” returnTrip-” 20000” /5 


x/option” 
x/datax 
S: c€ok /5 
4-—————— “ 4-—————— “ 
I İ c——————- data — İ 
İ appl. İ İ relay İ 
)1 1 -- ok --——--—-- "əl 
4-—————— “ 4-—————— “ 


C: €data contente” £Content”3 
xoriginator identity-" apex-reportüexample.com” /5 
xrecipient identity”” fredüexample.com” /5 
xoption internal€”dataTiming” targetHopoe”all” 
mustUnderstande”true” translıDe”99”5 
xdataTiming noLaterThan-” 20000” /5 
x/option” 
xdata-content Name€” Content”x 
xstatusResponse translıDe”86”5 
xdestination identity”” barneyüexample.com”x 
xreply codee” 250” /5 
x/destination”x 
x/statusResponsex 
x/data-content” 
x/datax 
S: c€ok /3 


Kiyne, et. al. Standards Track TPage 61 


RFC 3342 The Application Exchange (APEX) Party Pack güly 2002 


2.1.2 Timing Error Report 


If the APEX report service (c.f., Section 6.2 of 111) is invoked to 
send a timing error report, it issues a data operation vith: 


o its originator identifying the report service associated vith the 
issuing relay 


o its recipient identifying the endpoint address of the originator 
associated vith the "dataTiming" option 


o its content consisting of a "statusResponse" element having: 


8 its "transID" attribute equal to the "transID" attribute of the 
"dataTiming" option 


8 and identifying the original recipient vith a permanent failure 
indicator 
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For example: 


C: c€data contente€” cid:180example.com”x 
xoriginator identity-” fredüexample.com” /5 
xrecipient identity”” barneyğüexample.com” /5 
xoption internal€”dataTiming” targetHopoe”all” 
mustUnderstand”€”true” transIDe”86”5 
xdataTiming noLaterThan”“” 6000” reportErrorse”true” /5 
x/option” 
x/datax 
S: cok /3 


some time later 


C: €data contente” 4Content”3 
xoriginator identity-" apex-reportüexample.com” /5 
xrecipient identity-” fredüexample.com” /x3 
xdata-content Name€” Content”x 
xstatusResponse translıDe”86”5 
xdestination identity”” barneyütexample.com”x” 
xreply codem” 550” /x 
x/destination”x 
x/statusResponsex 
x/data-content” 
x/datas 
S: €ok /3 


2.2 Reporting on Delayed Delivery 


The "reportAfter" attribute of the "dataTiming" option provides for 
the originator to be notified if delivery is delayed beyond a 
specified time. Delivery of the data is not affected. HNote that if 
the value of the "noLaterThan" attribute is non-zero, then it 
provides the operational upper-bounds for the "reportAfter" 
attribute. 
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If this option is present in the "data" operation (c.f., Section 
4.4.4 of 111) and the value of the "reportAfter" attribute is non- 
zero, then: 


o 


For Step 5.2 of Section 4.4.4.1 of (11: 


Immediately prior to sending the data to the next relay, the value 
Of the "reportAfter" attribute is adğusted to reflect the 
processing time of the data at the local relay (e.g., the time 
required to determine the next relay, to successfully issue a 
"bind" operation, and then be ready to immediately issue a "data" 
operation). 


If the value of the "reportAfter" attribute becomes less than or 
equal to zero, then its value is set to zero and the APEX report 
service is invoked to send a transient timing report, regardless, 
the data element is sent to the next relay. 


For Step 5.3 of Section 4.4.4.1 of (11: 


If the relay does not receive an "ok" element from the recipient 
endpoint vithin the number of milli-seconds indicated by the value 
Of the "reportAfter" attribute, then its value is set to zero and 
the APEX report service is invoked to send a transient timing 
report. 


2.2.1 Transient Timing Report 


If the APEX report service (c.f., Section 6.2 of 111) is invoked to 
send a transient timing report, it issues a data operation vith: 


o 


Kilyne, 


its originator identifying the report service associated vith the 
issuing relay 


its recipient identifying the endpoint address of the originator 
associated vith the "dataTiming" option 


its content consisting of a "statusResponse" element having: 


8 its "transID" attribute equal to the "transID" attribute of the 
"dataTiming" option 


” and identifying the original recipient vith a transient success 
indicator 
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For example: 


C: €data contente€” cid:180example.com”x 
xoriginator identity-” fred€example.com” /x” 
xrecipient identity”” barneyüexample.com” /5 
xoption internal”€”dataTiming” targetHope”all” 
mustUnderstand””true” transIDe”86”5 
xdataTiming reportAfter-” 60000” /5 
x/option” 
x/datax 
S: €ok /3 


some time later 


C: €data contente” 4Content”3 
xoriginator identity-" apex-reportüexample.com” /5 
xrecipient identity-” fredüexample.com” /x3 
xdata-content Name€” Content”xv 
xstatusResponse translIıDe”86”5 
xdestination identity”” barneyütexample.com”” 
xreply codem” 350” /x 
x/destination”x 
x/statusResponsex 
x/data-content” 
x/datax 
S: c€ok /3 


3. The holdi4Endpoint Option 


Section 5.3 contains the APEX option registration for the 
"hold4Endpoint" option. 


The default behavior of the APEX relaying mesh, in the absence of 
processing options, is to silently drop data for a recipient if its 
endpoint isn”t attached. The "holdi4Endpoint" option provides for 
data to be queued if the recipient endpoint is not attached. 
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If this option is present in the "data" operation (c.f., Section 
4.4.4 of 111), and the value of the "holdiEndpoint" attribute is true 


then: 
o For Step 5.3 of Section 4.4.4.1 of 111: 


If the recipient”s endpoint is not currently attached, the relay 
vill queue the data vaiting for an application to attach as that 
endpoint. 


Note that in the absence of an upper-bounds on delivery, such as 
limits provided by the dataTiming option (Section 2), the data vill 
be queued indefinitely for the endpoint. 
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For example: 


C: €data contente€” cid:180example.com”x 
xoriginator identity-” fred€example.com” /x” 
xrecipient identity-” barneyğüexample.com” /5 
xoption internal” hold4Endpoint” /5 
xoption internal€”dataTiming” targetHopoe”all” 
mustUnderstand””true” transIDe”86”5 
xdataTiming noLaterThan—“” 60000” /5 
x/option” 
x/datax 
S: c€ok /2 


some time later the recipient”s endpoint attaches 


C: cattach endpointe” barneytexample.com” trans1IDe”2”75 
xoption internal”€”attachOverride” transIDe”3” /x5 
x/attach” 
S: c€ok /2 


C: c€data contente€” cid:180example.com”x” 
xoriginator identity-” fred€example.com” /x” 
xrecipient identity“” barneyğexample.com” /5 
xoption internal” hold4Endpoint” /5 
xoption internal“”dataTiming” targetHopoe”all” 
mustUnderstand””true” transIDe”86”5 
xdataTiming noLaterThane” 18000” /5 
x/option” 
x/datax 
S: cok /5 
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4. The dataHopping Option 


To detect misconfigurations that cause forvarding loops in the APEX 
relaying mesh, the APEX pubsub service re-introduces a mechanism 
similar to the IP TTL /(21l mechanism, in the form of an APEX option. 
Section 5.4 contains the APEX option registration for the 
"dataHopping" option. 


If this option is present in the "data" operation (c.f., Section 
4.4.4 of 111) and the value of the "noMoreThan" attribute is non- 
zero, then: 


o For Step 5.2 of Section 4.4.4.1 of 111: 


Immediately prior to sending the data to the next relay, the value 
Of the "noMoreThan" attribute is reduced by 1. 


If the value of the "noMoreThan" attribute becomes less than or 
equal to zero, an error in processing has occurred, the data 
element is not sent to the next relay, and if the "reportErrors" 
attribute is true, the APEX report service is invoked to send an 
error report. 


Further, note that because this option is processed on a per-hop 
basis, the originator must set the "targetHop" attribute to the value 
"all" and the "mustUnderstand" attribute to the value "true". 


If the APEX report service (c.f., Section 6.2 of 111) is invoked to 
send an error report, it issues a data operation vith: 


o its originator identifying the report service associated vith the 
issuing relay 


o its recipient identifying the endpoint address of the originator 
associated vith the "dataHopping" option 


o its content consisting of a "statusResponse" element having: 


8 its "transID" attribute equal to the "transID" attribute of the 
"dataHopping" option 


and identifying the original recipient vith a permanent failure 
indicator 
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For example: 


C: cdata contente€” cid:180example.com”x” 
xoriginator identity-” appl-pubsub/topice-fredütexample.com” /5 
xrecipient identity“” barneyğexample.com” /5 
xoption internal””dataHopping” targetHope”all” 
mustUnderstand””true” transIDe”86”5 
xdataHopping noMoreThane”2” reportErrors“”true” /5 


x/option” 
x/datas 
S: cok /5 
3-——————— .. 3-——————- .. 
l İ -- data ------- ssil I 
İ relay İ İ relay İ 
İ 91 İİ -—------- ok - İl 1$2 İ 
3-—————— .. 3-——————- .. 


C: €data contente€” cid:180example.com”x 
xoriginator identity-” appl-pubsub/topice-fredütexample.com” /5 
xrecipient identity“” barneyğexample.com” /5 
xoption internal””dataHopping” targetHope”all” 
mustUnderstand””true” trans1IDe”86”5 
xdataHopping noMoreThane”1” reportErrorse”true” /5 
x/option” 
x/datas 
S: c€ok /3 
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relay £2 determines that further relaying is necessary: 


C: €data contente” £Content”3 
xoriginator identity-" apex-reportüexample.com” /5 
xrecipient identity-" appl-pubsub/topic-fredüexample.com” /5 
xdata-content Name€” Content”xv 


xstatusResponse transıDe”86”5 


xdestination identity”” barneyütexample.com”x” 
xreply codem” 550” /x 
x/destination” 
x/statusResponsex 
x/data-content” 
x/datas 
S: cok /3 


5. Initial Registrations 


The APEX option registration template is defined in Section 7.1 of 
(11. 


5.1 Registration: The attachOverride Option 


Option Identification: attachOverride 


Present in: APEX”s "attach" element 


Contains: nothing 


Processing Rules: c.f., Section1 


Contact Information: c.f 


., the "Authors” 
memo 


Addresses" section of this 
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5.2 Registration: The dataTiming Option 
Option Identification: dataTiming 
Present in: APEX” s "data" element 
Contains: dataTiming (c.f., Section 6) 
Processing Rules: c.f., Section 2 


Contact Information: c.f., the "Authors” Addresses" section of this 
memo 


5.3 Registration: The holdiEndpoint Option 


Option Identification: hold4d4Endpoint 
Present in: APEX” s "data" element 
Contains: nothing 

Processing Rules: c.f., Section 3 


Contact Information: c.f., the "Authors” Addresses" section of this 
memo 


5.4 Registration: The dataHopping Option 
Option Identification: dataHopping 
Present in: APEX” s "data" element 
Contains: dataHopping (c.f., Section 6) 
Processing Rules: c.f., Section 4 


Contact Information: c.f., the "Authors” Addresses" section of this 
memo 
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6. The APEX Party Pack DTD 
xil 
DTD for the APEX option party pack, as of 2001-05-14 
Refer to this DTD as: 
KIİENTITY $ APEXPARTY PUBLIC "-//IETF//DTD APEX PARTY//EN" ""S 
“APEXPARTY, 


-— 


KİENTITY $ APEXCORE PUBLIC "-//IETF//DTD APEX CORE//EN" 
SAPEXCORE, 


ozu 
DTD data types: 


entity syntax/reference example 
hopcount 
HOPS 0..255 17 


milli-seconds 
MILLISECS 0..2147483647 60000 
-—— 


KİENTITY HOPS "CDATA"S 
KİENTITY 6 MILLISECS 


o 


"CDATA"S 


XİELEMENT dataHopping EMPTY” 
XİATTLIST dataHopping 
noMoreThan S5HOPS, m.ö 
reportErrors 
(truelfalse) "false"” 


XİELEMENT dataTiming EMPTY” 
XİATTLIST dataTiming 


noLaterThan $5MILLISECS, möv 
returnTrip SMILLISECS, 20 
reportAfter SMILLISECS, "or 
reportErrors 

(true false) "false"” 
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7. Security Considerations 


Consult fİl1”s Section 11 for a discussion of security issues. 


In 


o 


addition: 


The dataTiming option (Section 2) may be used to expose private 
netvork topology. Accordingly, an administrator may vish to 
choose to disable this option except at the ingress/egress points 
for its administrative domain. 


o The holdiEndpoint option (Section 3) may be used to facilitate 
denial-of-service attacks. Accordingly, an administrator may vish 
to impose administrative limits on this attribute (e.g., alvays 
require that the "dataTiming" option also be present vitha 
short-lived "noLaterThan" attribute). 
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Appendix A. Acknovledgements 
The authors gratefully acknovledge the contributions of Chris Nevman 
and Bob MVyman. Further, the dataTiming option is similar in function 
to "Deliver By" SMTP service extension defined by Dan Nevman in 131. 


Appendix B. IANA Considerations 


The IANA completed the registrations specified in Section 5. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2002). All Riohts Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative vorks that comment on or othervise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in vhole or in part, vithout restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative vorks. Hovever, this 
document itself may not be modified in any vay, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in vhich case the procedures for 
copyrights defined in the Internet Standards process must be 
folloved, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and vill not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL NARRANTIHS, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY VARRANTY THAT THE USE OF THE INFORMATION 
HEREIN NILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED VARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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